Subject: TRS clarification request

From: Mike Evans <[email-masked]>
Date: Wed, 13 Dec 95 17:23:00 GMT

We have recently hit a problem in the TRS topology database manager with HPR 
capable nodes in the network, which looks like it is a problem in the 
current architecture.

Consider two network nodes A and B, where A is HPR-capable and B is not. 
 The two nodes establish CP-CP sessions, and topology information is 
exchanged.

B then goes down, and comes back up as an HPR-capable node.  It sends an 
initial TDU to A informing it of this fact; however, the TG resource in the 
TDU has the same RSN as that stored in A's database.  A compares RSNs, finds 
they are the same, then compares characteristics and finds that they are 
also the same, and hence removes the resource update from the TDU.

Node A has thus failed to notice that the HPR support bit, which is held in 
the TG descriptor vector, has changed.

Under these circumstances, the pseudo-code in the Architecture Reference 
says that the action performed depends on the comparison

  If RCVD_CHARACTERISTICS = STORED_CHARACTERISTICS then

However, it is not defined precisely what is meant by these terms.  At first 
glance, it might appear that a byte by byte comparison of the node or TG 
characteristics vector is all that is required, but we have seen that bits 
of the TG descriptor vector must also be compared.

The other extreme is to compare the entirety of the descriptor and 
characteristics control vectors.  However, this can not be done in a 
byte-by-byte fashion, since two TG descriptor control vectors can contain 
identical information, but with their subfields arranged in different 
orders.  Checking each subfield independently is fairly complex (especially 
allowing for unknown subfields).

This raises several questions.

 -  What is currently intended by the terms RCVD_CHARACTERISTICS and 
STORED_CHARACTERISTICS?

 -  If more than just the characteristics CVs must be compared, how should 
that comparison be performed.

 -  If a byte-by-byte comparison is intended, is it reasonable for the 
architecture to assume all products will be consistent in the ordering of 
subfields in originated topology updates and will not reorder the subfields 
in stored and forwarded topology updates?

Our view is that

 -   a product should compare all CVs it knows about (unless the 
architecture explicitly states that a CV should not be compared - for 
example the Topology Resource Descriptor CV)

 -   the check should be a byte-by-byte comparison of the control vectors

 -   the architecture should state that products must be consistent in the 
ordering of subfields in originated topology updates and must preserve the 
order of subfields in any topology updates it stores and/or forwards.

This strategy will only work if this last point is simply documenting 
current practice (which we believe it is).  If any existing products do not 
adhere to these rules, then where the control vector contains subfields, the 
check should include a byte-by-byte comparison of the individual subfields.

Mike Evans
Data Connection Ltd